Domain name acquisition and management system and method

ABSTRACT

A preferred embodiment of the present invention can accept an indication of a domain name or set of domain names from interested entity. The desired domain names are names that an interested entity desires to register through a domain name registration system or systems, such as that operated by a registry-accredited registrar. The system can closely monitor the domain name registry or registrar databases used to provide domain name resolution or registration over a distributed network, such as the Internet, and determine the expiration or availability of the name or names supplied by the interested entity. When a desired domain name appears to be available, the system can register or re-register the domain name through a domain registration service. If there is more than one interested entity for a domain name, the system can also facilitate an auction for the domain name.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/377,792, filed on Mar. 15, 2006, which is a divisional application ofand claims priority from U.S. application Ser. No. 10/016,497 filed Nov.1, 2001, now issued U.S. Pat. No. 7,418,471, which in turn claims thebenefit of U.S. Provisional Patent Application No. 60/245,102, filedNov. 1, 2000, and U.S. Provisional Patent Application No. 60/248,341,filed Nov. 13, 2000, all incorporated herein by this reference.

COPYRIGHT NOTICE

© 2001-2006 SnapNames.com, Inc. A portion of the disclosure of thispatent document contains material which is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent document or the patent disclosure,as it appears in the Patent and Trademark Office patent file or records,but otherwise reserves all copyright rights whatsoever. 37 CFR §1.71(d)-(e) (2000).

TECHNICAL FIELD

The present invention relates to the field of managing identificationresources, and, more specifically, to domain name registration andmanagement on a distributed computer network, such as the Internet.

BACKGROUND OF THE INVENTION

In distributed computer networks, being able to locate individualcomputers, servers, or various other machines on the network iscritical. On the Internet, one of the most valuable identificationresources is the domain name. Internet domain names provide a convenientway to reference Internet Protocol (IP) numerical addresses. Presently,IP addresses are 32-bit integers. They comprise four numbers separatedby periods. Every “host” machine (e.g., computer, etc.) connected to theInternet must be identifiable by a specific numerical IP address.However, people prefer to reference host machines by pronounceable,easily remembered names, referred to as “domain names.” The Internetimplements a Domain Name System (DNS) to facilitate matching specificdomain names to specific hosts.

The DNS is a distributed database system that allows computerapplications to map between domain names and IP addresses. The DNS alsoprovides electronic mail routing information and many other services.Individual components of the DNS distributed database can be cachedlocally, or stored on any of numerous distributed machines. The DNS datacorrelates each domain name to a specific numeric IP address. If acomputer's local cache does not have the information to resolve a domainname into an IP address, it sends a request to other computers that maycontain the resolution information. The DNS affords a domain name somemeasure of independence from the physical location of a host. The hostcan be moved to a new location on the network, but it can still beaccessed using the same domain name. As long as a user can remember thedomain name, the host can always be located, even if the IP addresschanges over time. This illustrates the value of a domain name that iseasy to remember.

Physically, the DNS comprises many servers and other computers ormachines that run software and store data permitting computers to querythe DNS database. One such machine is the “root server.” A root serveris a server computer that maintains the software and data necessary tolocate “name servers” that contain authoritative data for a specificdomain, such as the “.com” top level domain. There are presentlythirteen root servers throughout the world. Name servers are computersthat have the software and data to resolve the domain name into an IPaddress. The data accessible through the name server is often referredto as a “zone file.” A “zone” is a subset of the total domain namespace. The domain names in that subset are stored in the zone file forthat name server. There is a zone file for each domain space (i.e.,zone).

The DNS is organized in a hierarchical, tree structure. A domain name isthe label representing a specific domain within the total possibledomain space available in the DNS. The highest level in the DNShierarchy is the “root,” which is technically unnamed but often referredto as the “.” or “dot.” The level immediately below the root in the DNShierarchy is the top-level domain, or “TLD.” It is called the “top-leveldomain” because it is the highest level in the hierarchy after the root.The TLD appears furthest to the right in an English-language domainname. For example, “gov” in the “uspto.gov” domain name. There arevarious types of TLDs. The term “gTLD” is interchangeably used to referto a “global top-level domain” or a “generic top-level domain.” A globalTLD is one that can be registered by an entity regardless of theentity's geographic location or political boundary. For example, aperson, corporation, or other entity located anywhere in the world canregister a name in the “.com” domain. However, because an entity musthave a presence in the United Kingdom to register a name in the “. uk”TLD, that domain is not a global TLD. Similarly, a generic TLDrepresents a domain in which an entity can register a name regardless ofwhat type of entity it is. For example, because any entity can registera name in the “.com” domain, while only military entities can register aname in the “.mil” domain, the “.com” domain is an example of a genericTLD and the “.mil” domain is an example of a “specific TLD.” The “.uk”domain is also an example of a “country code” TLD, or “ccTLD,”applicable to the United Kingdom. Other examples of ccTLDs include “.fr”for France, “.ca” for Canada, “.jp” for Japan, and “.us” for the UnitedStates of America.

By registering a domain name in a particular TLD, the TLD is sub-dividedinto lower levels in the DNS hierarchy. A second-level domain is thelevel in the DNS hierarch immediately below the TLD. An example of asecond-level domain would be “snapnames” in the “snapnames.com” domainname. The level in the DNS hierarchy immediately below the second-leveldomain is the third-level domain. An example of the third-level domainwould be “portland” in the “portland.or.us” domain name. Furthersubdivisions can be created in a similar manner. Domain names at eachlevel of the hierarchy must be unique. Thus, while there can be only one“snapnames” registered in the “.com” TLD, there can be a “snapnames.net”domain name.

Historically, domain name registration has been conducted under a SharedRegistration System (SRS). The SRS was created by Network Solutions,Inc. in 1999 to provide a registry backend through which multiple,globally diverse registrars could register domain names. The term“registry” refers to the entity responsible for managing allocation ofdomain names within a particular name space, such as a TLD. One exampleof a registry is the VeriSign, Inc. registry for the .com, .org, and.edu TLDs. The term “registrar” refers to any one of several entitieswith authority to add names to the registry for a name space. Entitiesthat wish to register a domain name do so through a registrar. The term“registrant” refers to the entity registering the domain name. In somename spaces, the registry and registrar functions can be operated by thesame entity, so as to combine the concepts and functions of the“registrar” and “registry.” The combined registry-registrar model isimplemented in many ccTLDs and a few gTLDs. The overall registrationsystem, including multiple registries, is overseen by the InternetCorporation for Assigned Names and Numbers (ICANN). ICANN is anon-profit corporation responsible for the IP address space allocation,protocol parameter assignment, domain name system management, and rootserver system management functions previously performed under U.S.Government contract by the Internet Assigned Numbers Authority (IANA)and other entities.

Domain names have become important assets for individuals, businesses,and organizations alike. At the same time, they are difficult to keeptrack of and can be lost in several ways. There are many examples ofdomain names being hi-jacked by hackers or cybersquatters with maliciousintent. A disgruntled webmaster can walk away with a critical domainname. Domain names can be lost accidentally by a registrar. In addition,an owner simply forgetting to renew a subscription will often result indomain name loss.

Even though they are quite valuable, only approximately 10% of theregistered domain names are actually in use; that is, resolving toactive Web sites with more than token content. There are many people whowould like to use a domain name that is registered by someone else butnot in use. Additionally, there are individuals who own domain names butdo not have immediate plans to use them and who would be willing totransfer them to another individual for appropriate compensation.

Registration of available names is currently done on a first-come,first-served basis. Even after an entity registers a domain name, ifthey allow the registration to lapse, someone else may register thename. If an entity wishes to register a domain name that is currentlyregistered to someone else, that entity would manually have to check thedomain name registry with great frequency to ensure they will be thefirst to request registration of the name when it becomes available. Ifa registrant mistakenly forgets to renew the registration and the namebecomes available, the former registrant would have to attempt tore-register the domain name as quickly as possible, before some otherentity requests registration of that name. Registrants have never had anefficient and reliable system to prevent inadvertent loss of a domainname registration. Neither have registrants nor other interestedentities had a means for ensuring successful registration of a domainname once it becomes available.

What is needed is a system to provide an efficient, organized, andreliable method for tracking, acquiring, and protecting Internetidentification resources such as domain names. The present inventionfulfills this need.

SUMMARY OF THE INVENTION

A preferred system consistent with the present invention will accept asingle or set of desired domain names from an individual entity oranother system (referred to herein as an “interested entity”). Thedesired domain names are names that an interested entity desires toregister through a domain name registration system or systems, such asthat operated by a registrar.

The present system will closely monitor the domain name registry andregistrar databases used to provide domain name resolution orregistration on the Internet, or any other network, and determine theexpiration, deletion and impending purge from the central registry,and/or availability of the name or names supplied by the interestedentity. This domain name database monitoring can be performed by amanual, semi-automated, or fully automated process.

When a desired domain name appears to be available, the system willattempt to register or re-register the domain name through a domainregistration service. The process of registering the desired name ornames can be manual, semi-automated, or fully automated. If there ismore than one interested entity for a particular second-level domainname (e.g., “snapnames,” without regard to the TLD), the presentinvention can also facilitate an auction of that second-level domainname.

Additional objects and advantages of this invention will be apparentfrom the following detailed description of preferred embodiments thereofwhich proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 diagrams one embodiment of a system according to the presentinvention.

FIGS. 2A-2F provide illustrative examples of the types of data recordsand data fields that can be stored in databases of the system of FIG. 1.

FIG. 3A diagrams a typical deletion cycle for an expiring domain name.

FIG. 3B schematically illustrates communications links for an DeletingDomain Name Acquisition Cluster used to register deleting domain names.

FIG. 3C is a communications flow diagram illustrating the typicalcommunications during operation of the domain name acquisition array andacquisition routine components of the Deleting Domain Name AcquisitionCluster of FIG. 3.

FIG. 4 schematically illustrates an event decoder routine's connectionwith a system comprising one registry and multiple registrars.

FIG. 5 schematically illustrates an event decoder routine's connectionwith a system comprising multiple registries and multiple registrars.

FIG. 6 schematically illustrates an alternate embodiment of an eventdecoder routine's connection with the system of FIG. 5, in which theevent decoder routine employs a direct connection with a registry.

FIG. 7 depicts a pinging process consistent with the present invention.

FIG. 8 depicts an alternative to the pinging process of FIG. 7, operatedas an accelerated pinging process.

FIG. 9 schematically illustrates a Registrar to Registry Protocol andWHOIS event decoder process.

FIG. 10 illustrates a Registrar to Registry Protocol event decodeprocess.

FIG. 11 schematically illustrates a WHOIS event decode process.

FIG. 12 illustrates a flow diagram for an auction process used toselectively identify second-level domain names suitable for auctioningand facilitate an auction of the identified second-level domain names.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

A preferred embodiment of the present invention is designed to monitordomain name registration record additions, changes, and deletions fromregistry and registrar databases and immediately acquire or re-acquire adesired domain name if it becomes available. Prior to this invention, tobe confident of renewal, a registrant of a domain name had to calendarthe renewal date of its domain name and manually renew the domain namebefore the renewal period ended. Failure to do so could result inexpiration of the registration, loss of ownership of the domain nameupon deletion of the name by the registrar, and purge by the centralregistry.

The present invention can help mitigate these problems in at least twoways. First, it provides prompt notification to registrants (or otherinterested entities) of any changes in the domain name record. Thisallows earlier action to mitigate the effects of oversight or maliciousintent. Secondly, it will re-acquire the name automatically if theregistration is accidentally allowed to expire and the name goes intothe delete cycle. This obviates the need for a registrant to purchasethe name back from someone else, sometimes at a very high cost, or tolitigate over the name. It also helps prevent discontinuity in servicesusing the registered domain name.

The present invention can also serve the needs of people who want toacquire a domain name that they do not presently own. Traditionally, aperson wanting a domain name that was registered by another entity wouldperiodically and manually have to check its availability. Such a processis time-consuming and often results in losing the domain name to someonewho sees that it is available. There are no entities operating in asafeguarding capacity to receive an indication of a desired domain namefrom an interested third party in order to reliably monitor the domainname and register it on behalf of the interested third party at somelater time when the domain name becomes available. An embodiment of thepresent invention allows an entity that desires a domain name to waitfor the domain name registration to expire, knowing that when it expiresand deletes from the registry, the entity should be able to register thename before anyone else does. It is a way to get “next in line” for thename. Two ways the present invention can accomplish this are throughmaking periodic registration requests and forming contractual allianceswith one or more domain name registrars. Other ways include integratingtechnology at the registry level or striking contractual alliances withregistries.

A preferred embodiment of the present invention comprises a program thatstores information about people, corporations, or other interestedentities desiring specific domain names, and it regularly polls majordomain name registrars, the central registry, or the combined entity, asappropriate, to check the availability of the desired names. Softwareconsistent with the present invention can be implemented directly on thenetwork to facilitate access by remote users. For each interested entitywanting one or many domain names, the software or system can store theperson's name, address, credit card number, and other useful businessinformation necessary for providing technical, billing, andadministrative contact information to the registry and registrar WHOISdatabases, as well as a list of domain names that person is interestedin acquiring.

The present invention can then periodically and automatically check withone or more combined registries/registrars or a central registry andautomatically register a name if the name is available, or re-register aregistered name if the registration period has expired and the name isabout to delete. The periodicity can be varied programmatically.Availability information can be determined by periodically pinging orpulling data from the data sources, or by establishing partnerships withthe data sources, whereby the data source will periodically push data toa system embodying the present invention.

FIG. 1 depicts a system consistent with the present invention. A searchagent 102 can be provided to access one or more domain name registrars104 to register or re-register domain names. The search agent 102 can bemade accessible to the general public via a Web site. Confirmation,information requests, or other relevant communications can be sent to aremote network user through e-mail 106 or other appropriatecommunications channels. The search agent 102 can access one or moredatabases containing pertinent information. Examples or such databasesinclude a customer database 108, a desired domain name database 110, andan attempt database 112 for tracking attempts made to register orre-register the domain names stored within the desired domain namedatabase 110 or for WHOIS look-ups. Additionally, a seller database 114can be maintained to store information about entities wishing to sell aregistered domain name.

FIGS. 2A-2F provide illustrative examples of the types of data recordsthat can be stored in various databases in a system consistent with thepresent invention. These include the customer database 108, desireddomain name database 110, and attempt database 112 of FIG. 1. Theseexamples are for illustrative purposes only, and an individual skilledin the art will readily see that various other types of data could bestored as well. The actual data stored in the databases, the datafields, or even the types of databases, can depend on the particularimplementation and functionality desired. Other commonly stored data caninclude technical, administrative, and billing contact informationtypically used to populate registry or registrar WHOIS databases.

If an interested entity has provided credit card or other billinginformation to the system, the interested entity can elect to have thesystem automatically register the name if it becomes available. In thealternative, a domain name can be registered in the name of a trustee orescrow agent and subsequently transferred to the interested entity.Billing information can be encrypted for secure storage and additionalsecurity. The system can be set to check the availability or status ofnames at any periodicity. For example, the present system can affordsufficient flexibility to allow the status of a name to be checked withgreater frequency around the time of the name's anticipated date ofdeletion from the central registry. The system can also be operated onbehalf of one particular interested entity, or it can be made availableto the public generally, in which case priority rules can be implementedto ensure an orderly process.

In one embodiment, implementations of the present invention can generaterevenue by charging one or more service fees for checking names,informing individuals of changes to the domain name records, andregistering desired names that become available. To maximize the utilityand ease-of-use of the present invention, billing for services tointerested entities can be at any convenient frequency (for example,monthly or yearly). In addition, attempts to register domain names, orother records, routinely can be time- or date-stamped to produce anaudit trail that is available at substantially any time.

Description of Acquisition Services and Monitoring Services

A preferred embodiment of the present invention can include severalaspects or different services. As one alternative, these services can beprovided as part of an ongoing business concern. The following twoservices are particularly valuable components of the present invention:domain name acquisition services and domain name monitoring services.

Acquisition services can include several different components. Forexample, the scope of acquisition services can encompass monitoring allchanges in the registration record for a given domain name. Subscribersof the service can be instantly alerted (or they can designate an agent,such as an attorney, to be alerted) in the event of a change to theregistration record. If the registration expires and the domain deletes,the domain name can be acquired automatically and instantly on behalf ofthe subscriber. These and other related services can be offered for afee by a business implementing the present invention, and a money-backor similar guarantee can be offered if a name is not registered orre-registered upon deletion of the prior name. Value-added services canalso be provided. Once such example would be a periodic newsletter orjournal summarizing current issues of upcoming events. If only onecustomer of this service is allowed for any given domain name, then thatcustomer can be virtually assured that the domain name will besuccessfully registered to them once the prior registration expires andthe name deletes. Customers of a business implementing this inventioncan include such likely candidates as current domain name registrantsthat wish to protect their registration(s), as well as prospectiveregistrants that wish to get “next in line” to acquire a domain namewhen the prior registration expires and the name is deleted by thecentral registry. Embodiments of the acquisition service may also beimplemented to attempt to acquire an advanced registration orreservation for a domain name as new domains (TLD or domains at otherlevels) are created.

Monitoring services can be offered independently from or in addition toacquisition services. A business providing monitoring servicesconsistent with the present invention could monitor changes in thedomain registration record for a domain name indicated by a servicesubscriber, and the subscriber can be notified of changes in the record.News, information, and events can also be offered in a periodic journalor newsletter offered with the service. Unlike for the acquisitionservice, the monitoring service can have multiple subscribers per domainname. However, unless someone has subscribed to the acquisition service,registration or re-registration of the domain name would still be on afirst-come, first-served basis. Monitoring services can be used byprospective domain registrants to track either active or inactivedomains, and to track a competitors' movements. The monitoring servicescan also help indicate interest in a particular domain name. This levelof interest can help identify domain names that would be good candidatesfor auctions.

Domain Name Deletion and Registrability Timing

In order to appreciate the acquisition or reacquisition process andtiming, it is first helpful to understand the current process and timingfor expiration and deletion of domain name registrations. Understandingthe process highlights the advantages of the present system and methodfor reacquiring deleted domain names. Typically, domain namesregistrations expire and delete according to the timeline illustrated inFIG. 3A. FIGS. 3B and 3C illustrate the use of domain name acquisitionarrays to acquire available domain names with a high level ofreliability.

FIG. 3A illustrates a typical deletion cycle, although variousexceptions or alternative timelines can exist. One such exception hasbeen with the deletion cycle for which Network Solutions, Inc. served inboth the registrar and registry capacity for a particular domain name.Expired domains names were, and sometimes still are, deleted from thepurge queue in a much less predictable fashion. However, illustrating atypical example of the deletion cycle, FIG. 3A emphasizes four instancesor transaction events. At point A, a domain name is registered. At pointB, the domain name registration expires. At point C, the registrardeletes the domain name record. At point D, the registry purges thedeleted domain name record. The period between the points A and B can beup to ten years, in one-year intervals. The registrant typicallyreceives renewal notices from the registrar as the expiration dateapproaches. If there is no response or renewal from the registrant, theregistration expires at point B. When this occurs, the registry willautomatically renew the domain. The registrar will now have a window ofapproximately thirty to forty-five days, sometimes longer (the periodbetween B and C), in which to delete the domain and effectively cancelthe registry's auto-renewal. If the registrar does not cancel theregistration before point C, the domain will be renewed for a one-yearperiod and the registrar is committed to the fee charged by the registryfor a one-year registration.

During the period between points B and C, the registrar may opt to putthe domain on “registrar-hold.” This hold will remove the domain fromthe global Domain Name Servers effectively disabling the domain unlessthe registrar is paid for the renewal. If the registrar deletes thedomain before point C, the domain will exist in a purge queue at theregistry for approximately 120 hours (between points C and D) beforefinal deletion. In this state, the domain name is not available forregistration and will not be active. After point D, registration of thedomain is “up for grabs” on a first-come, first-served basis through anyauthorized registrar.

Until the registration expires 300, the domain record is in the zonefile for the relevant domain. For a short period after the expiration302, the domain record is still cached at local root name servers, butpropagation of the change across all servers is not complete. Servicessuch as a Web site and e-mail for that domain name will still work whilethe domain is listed in the root name servers. After the domain namerecord is off the name servers, my associated Web site and e-mail stopfunctioning. During the period 304 between the domain name beingregistered and the registration being purged, the record is still in theSRS. After the name is no longer in the SRS, it is available for asubsequent registration. For the period 306 after the record is nolonger in the root servers but before it is purged, the Web site ande-mail for that domain name no longer function, but the name is notavailable for registration by the general public.

Acquisition Engine Array for Successful Acquisition of Deleted DomainNames

As can be seen with reference to FIG. 3A, punctual timing is crucialwhen trying to register a recently available domain name. Embodiments ofthe present invention achieve a high success rate in domain nameacquisition either by implementing a “deleting domain name acquisitioncluster,” which is a distributed system designed to monitor and registerdomain names as soon as possible after they are deleted from a registry,or by integrating an acquisition engine directly into the registrysystem. The components of an acquisition array system include a frontend that receives requests from customers wanting to register soon to bedeleting domain names, a processing and distribution engine, and one ormore acquisitions arrays that operate in connection with a registrar'ssite for direct communications with a registry to perform the necessaryoperations to monitor and add domain names. The manner in which thesevarious components communicate with each other is schematicallydiagrammed in FIG. 3B.

In FIG. 3B, domain names are identified in any reasonable manner byinterested entities. Methods can include a Web site, e-mail, fax, directcustomer call-in, or any suitable method that allows domain names to bedelivered to the processing and distribution engine. This is illustratedwith the front end deleting domain name retail interface 324 in FIG. 3B.The interface 324 communicates with the processing and distributionengine 320 via communications channel A.

Once domain names have been transmitted to the database in theprocessing and distribution engine 320, they are evaluated to establishtheir current state in the deletion cycle. The process of evaluationcollects data, using channel B in FIG. 3B, from the public WHOIS serversat the registry or registries and, if necessary, the registrar 326.Domain names found to be in a state of near availability (such as thosewith a status ranging between points B and D in FIG. 3A) aretransmitted, through any or multiple of the various channel C pathways,to one or more of the acquisition arrays 328. The transmission protocolis typically a Secure Socket Layer (SSL) encrypted TCP/IP connectionestablished over the Internet from a central site to each individualacquisition array 328. Each acquisition array 328 communicates with oneor more registries 330 through the registrar via the registrar'sregistry protocol connection with each registry, illustrated bycommunications channels D. Registry protocols can include RRP, EPP, orother present or future protocols. For simplicity, the term “RRP” isused herein to refer to any such acceptable communication, protocolbetween a registrar and a registry. FIG. 3B also illustrates a registrarAPI 332 for domain name registration. The registrars' API 322communicates with the processing and distribution engine 320 viacommunications channel E and is used to register a domain name with aregistrar.

Currently there are two methods by which a registry makes deleted domainnames available for re-registration once a registrar issues a deletecommand. The first is an immediate delete that will make the domain nameavailable for registration as soon as the registrar issues the deletecommand to the registry. The other method, referred to as a “batchpurge,” involves multiple domain names that are collected by theregistry after a registrar issues the delete command and then arereleased in a single batch. The acquisition arrays are designed tomonitor and acquire domain names regardless of the method the registryuses to make available deleted domain names.

Depending upon the mode of operation, results of the acquisition job caneither be transmitted back to the processing and distribution engine inreal time, or after a completed job in a batch. The resulting data canbe converted to reports that are distributed back to the relevantregistrar for accounting purposes and so that customer WHOIS data can bestuffed into the registrar's WHOIS database.

Each acquisition array 328 is an array of computers specificallydesigned to monitor and acquire deleting domain names that are expectedto become available during the registry's purge process. In analternative embodiment, an acquisition array 328 can be one computerwith multiple communication ports and processor resources sufficientenough to establish multiple RRP connections with the registry. Anacquisition array 328 is typically hosted at a registrar's site. Thecommunications software of an acquisition array is preferably limited toissuing only RRP “check” and “add” commands in accordance with limitsoutlined by the registry and any other standards agreed upon byoperators of the acquisition array and the host registrar, affectingsuch things as the rate of querying. The components of an acquisitionarray 328 are highly secure, with all communications using SSL-encryptedmessages, or other secure means, to communicate with the registry or thedomain name master database that stores the information about thedeleting names.

FIG. 3C illustrates a communications flow for domain name acquisitionduring a registry's “add storm.” While the following procedure isdescribed with respect to a single domain name, those skilled in the artwill readily ascertain that it can apply equally well to a list ofmultiple domain name. Acquisition of multiple domain names can beattempted in series or in parallel using multiple acquisition arrays orcommunication ports.

When it is determined that a domain name for which acquisition serviceswere requested has deleted and will soon be purged, the domain name isidentified in a transmission 340 sent to the acquisition array 328. Theidentification of the deleting domain name 340 originates from a“database and management system” 336. The database and management system336 includes the processing and distribution engine 320 of FIG. 3B and amaster database of domain names and registration information. Theidentification of the soon-to-be-deleted domain name 340 is routed to anacquisition array 328 located at a registrar's site where the domainname should be registered if successfully acquired. Alternatively, thedomain name can be identified to multiple acquisition arrays located atmultiple registrars. Such duplicated efforts would help ensuresuccessful acquisition of the domain name. The domain name can beregistered at the site of the registrar hosting whichever acquisitionengine successfully acquired the name. The deleting domain name can be,but it does not have to be, registered through the registrar of theprior registration.

Once the domain name (or list of domain names) is transmitted to theacquisition array 328, the array 328 attempts to acquire the domainnames during the “add storm,” when the registry purge cycle begins. Forthe VeriSign Registry, for example, the add storm comes on the heels ofa batch purge. Presently, this typically occurs around 2:00 p.m. E.S.T.Acquisitions are preferably accomplished by a series of check and addcommands. In FIG. 3C, the add storm procedures begins with a retrievalof a domain name from the acquisition array's acquisition routine 338and a query 342 of the domain name's availability from the registry 330.The registry 330 then returns a response 344 to the acquisition routine338. If the name is available, the acquisition routine 338 issues an RRPadd command 346, and a response 348 is returned from the registry 330.The acquisition routine 338 can repeat 356 for each domain name expectedto be deleted during that purge cycle; and it can repeat 356 to re-checkthe availability of a domain name if the domain name was not availableresponsive to the prior query 342. Return arrow 358 indicates that theprocess of FIG. 3C may repeat if the domain name is not purged from theregistry.

The rate of queries and the bandwidth consumed during the acquisitionprocess can be tuned daily. These parameters are set according to thenumber of domains in the batch, the quality of the domain name list(i.e., some domain names may be more important acquisitions thatothers—due to financial value or other considerations), and limits setby the registrar. After completion of the run, logging information istransmitted 350 back to the database and management system 336.Registrars 332 can then be notified 352 of successfully added domainnames and be sent the associated customer information necessary topopulate their WHOIS and customer databases 334 for the newly addeddomain names. The information necessary for populating the WHOISdatabases can be stored in the master databases of domain name andregistration information at the database and management system 336. Theregistrars 332 preferably acknowledge 354 receipt of the information.

Acquisition success is dependent, in large part, upon the total numberof connections to the registry, and the rate at which queries are made.In the current environment connections can become scarce during theperiod of the add storm. In a preferred embodiment, a minimum of threehundred connections are made available for use during the add storm.Generally, the more connections that are available, the betterconnections can also be acquired many hours in advance of the add stormacquisition run. When these connections are acquired they can be idledat a lower rate until the add storm begins. The domain names beingmonitored during this period also include names that are expected todrop off hours later—those not expected to be in the add storm. Theseare typically domain names held by registrars other than NetworkSolutions (now VeriSign).

Integration of the acquisition array on the registrar's site requiresthat connectivity can be established between the database and managementsystem, the registry, and the acquisition engine. Preferred ports foroperation are 648 to the registry, SSH, NTP, and an individuallyspecified port for the SSL encrypted messaging with the database andmanagement system. Dedicated routable IP addresses also should beprovided for the operation of the acquisition engine.

Procuring Information and Registering a Domain Name

It should be evident from the foregoing discussion that being wellinformed of domain name registration or deletion events is very usefulto systems embodying the present invention. Domain name status andinformation can be obtained from a registrar through various mechanisms.The first mechanism is through periodically “pinging” (or querying)registrars' servers to determine if a name is available, and if so, toregister the name. Information may also be obtained by directly pingingthe registry server. This would especially be the case in a “thickregistry system,” where the majority of registration information (suchas billing, administrative, and technical contact information) is storedat the registry level. In any embodiment, increasing the frequency ofthe ping helps ensure that the name can be registered to an entityemploying the present invention, and not to a third party.

An alternate preferred embodiment adopts a second mechanism forobtaining information and ensuring prompt registration. In the secondmechanism, partnerships or contractual agreements can be entered intowith the various registrars. As part of these relationships, eachregistrar can give operators of the present invention a right of firstrefusal to register a name that becomes available for registration ortransfer. For example, a registrar can notify an interested entity thata registrant will not be renewing a registration and the name willbecome available. As one option, the name can be renewed before it ispurged and transferred to the interested entity. This ensures that nothird party will be able to register a recently-available name before anoperator of the present invention has an opportunity to do so.Notifications to interested entities can use standard technology in theart of pushing data over a network to remote hosts. Conventionalcorrespondence (e.g., fax, telephone, mail, etc.) can also be employed.

The RRP event monitoring technology of the present invention can bedesigned to work regardless of the domain industry model. Today, themodel includes multiple registrars all connecting to a single global toplevel domain (gTLD) or country code top level domain (ccTLD) registry.This model will scale as new gTLD and ccTLD registries are added. Eventnotification can be transmitted either from the registrar or directlyfrom the registry. This can be accomplished by establishing apartnership with the registry operator. Also, most county code top leveldomain (ccTLD) registries work in the same manner as systems in whichthe registrar and registry functions are combined today.

The RRP was designed by Network Solutions, Inc. in order to facilitatethe Shared Registration System (SRS) that allows for multipleregistrars. The technology of the present invention anticipates that theRRP (or other suitable protocol) may be different with each new registryand is not dependent upon the current standards for its applicationprogram interface (API) to work in new, multiple-registry environments.

FIGS. 4-6 schematically illustrate various embodiments of thecommunications channels employable by the present invention. The presentinvention employs an event decoder routine to determine the status of adomain name through deciphering and handling the various types ofcommunications or information that can come from a registrar orregistry. As discussed below with respect to FIGS. 9 through 11, typicalevents handled by the event decoder routine include RRP events and WHOISevents. In particular, FIG. 4 illustrates the connections in a system inwhich an event decoder routine 400 is provided to monitor domain nameregistration activity with multiple registrars 402 a through 402 c and asingle registry 404. Registrar to registry protocol requests 406 athrough 406 c are sent from the registrars to the embodiment of thepresent invention 408 a through 408 c.

FIG. 5 illustrates the communication channels in a system in which anevent decoder routine 500 is provided to operates with respect tomultiple registrars 502 a through 502 c and multiple registries 504 aand 504 b. As illustrated in FIG. 5, the registrar to registry protocolrequests 506 a through 506 f are sent 508 a through 508 f from theregistrars 502 a through 502 c to the event decoder routine 500.

FIG. 6 illustrates communications channels of an alternative applicationof the present invention comprising multiple registrars and multipleregistries, and in which the event decoder routine employs a directcommunication channel with at least one registry. With particularreference to FIG. 6, the event decoder routine 600 is illustrated inconnection with multiple registrars 602 a through 602 c and multipleregistries 604 a and 604 b. Similar to FIG. 5, in FIG. 6 RRP requests606 a through 606 f are illustrated between the registrars 602 a through602 c and the registries 604 a and 604 b. For a registry 604 b withwhich the embodiment of the present invention 600 does not communicatedirectly, the registrar to registry protocol requests 606 b, 606 c, and606 f can be sent 608 b, 608 d, and 608 f to the event decoder routine600. However if the event decoder routine 600 an communicate directlywith the registry 604 a via a communications channel 610, then the eventdecoder routine 600 can receive and monitor domain name registrationinformation directly from the registry 604 a through the communicationschannel 610, rather than by receiving information from one of the RRPrequests 608 a, 608 c, and 608 e going to the registry 604 a with whichthe direct communications are established.

Standard Ping Process

In a preferred embodiment of the present invention, a standard pingingprocess can be used to query information sources such as: 1) theVeriSign Registry SRS using the RRP protocol; 2) the DNS root servers;3) the VeriSign Registry standard port 43 WHOIS server; 4) theregistrars standard port 43 WHOIS server; or 5) other relevant presentor future sources. It will be apparent to those skilled in the art thatthe present technology or suitable substitutes can be implemented toquery information from registries other than the VeriSign Registry.Thus, this aspect of the present invention is applicable to gTLDs,ccTLDs, and other domains.

The process can be summarized as follows: A domain name is retrievedfrom a database of desired domain names. These domain names have beenreceived from interested entities requesting acquisition or monitoringservices. The domain name's availability can be first checked at theVeriSign Registry using the RRP connection into the SRS. If the domainname is available and there is an interested party requesting thedomain, or if it is tagged for auction (as described below), it can beregistered immediately with a partner registrar. After the acquisition,the interested entity can be notified accordingly (either of thesuccessful acquisition, or of an upcoming auction).

If the domain name is not available for registration in the above check,embodiments of the present invention can still obtain information usefulto entities interested in monitoring the status of the domain name orparticipating in a future auction. Queries can be made against a DNSroot server(s), a registry WHOIS, and a registrar WHOIS, and acomparison made against the base data for changes that have been made tothe domain's registration information. If changes have been made, thecustomer requesting the monitoring will be notified with a detaileddescription of the changes.

FIG. 7 and FIG. 8 respectfully illustrate standard pinging andaccelerated pinging processes in more detail. With particular referenceto FIG. 7, the process begins at step 700. A desired domain name isretrieved from a database of desired domain names 702. In decision step704, the present invention can ping the applicable SRS resources todetermine if a domain name is available. If it is available, the systemverifies that there is an acquisition customer (i.e., an interestedentity desiring the domain name) 706. If there is not an interestedentity, the next determination is whether the domain is tagged forauction 708. If it is not, the process repeats with the step ofdetermining the availability of the same, or another, domain name 704.Continuing with decision step 708, if it is determined that the domainis tagged for auction, as illustrated in FIG. 12, the domain name isacquired in step 710 and potential buyers are notified of the auction,thus ending the pinging process 712 (although further efforts may bemade to facilitate the actual auction process). The domain name can beacquired and registered in the name of a party requesting theacquisition, if one exists, or it can be acquired by a entityspecifically designed to hold the domain name in escrow until thecompletion of a future auction.

Continuing with step 706, if there is an acquisition customer theprocess proceeds with step 714 and the domain name is acquired and theinterested entity is notified of the acquisition, thus ending thepinging process at step 716. Returning to step 704, if the domain nameis not available for registration, the system queries the DNS rootservers registry and registrar WHOIS databases in step 718. After step718, if the domain registration information or record is set to expirein less than a predefined limit, for example, 24 hours, as shown in step720, the system determines if it is beyond the time for acceleratedpinging 722. If it is not, the domain name is tagged for acceleratedpinging at step 724 and the process continues to steps 726 and 704. Ifit is beyond the time for accelerated pinging or if the domain name isnot set to be deleted in less than the predefined limit, the processcontinues with a determination of whether there has been a change inregistration information 726. If there has not been a change inregistration information, the process returns to the determination ofwhether the domain is available for registration 704. If there has beena change in registration information at step 726, the system determinesif there is an acquisition customer at step 728. If there is anacquisition customer at step 728 the customer is notified of the changeto the domain at step 730. The base record stored by the system is thenupdated at step 732 to reflect the changes in the registrationinformation detected at step 726. The process then continues by loopingback to step 704. If at step 728 it is determined that there is noacquisition customer, then the domain name record is tagged at step 734to provide the change in registration information to monitoringcustomers as part of a periodic notification service. The processcontinues with step 732 as described previously.

FIG. 8 illustrates a preferred embodiment of the accelerated pingingprocess. After the process begins at step 800, the system retrieves adesired domain name from the accelerated pinging queue or database 802.These are primarily names that are tagged for accelerated pinging duringthe process of FIG. 7. The next step is a determination of whether thedomain name is available based on queries of the SRS 804. If it is notavailable, the system returns to step 802. If the domain name isavailable, a determination is next made by the system as to whetherthere is an acquisition customer 806. If there is an acquisitioncustomer at step 806, the domain name is acquired at step 808 and theacquisition customer is notified of the successful registration of thedomain name. This ends the registration process at step 810. If there isno acquisition customer at step 806, the system makes a determination ofwhether the domain name is tagged for auction at step 812. If it is nottagged for auction, the process returns to step 802. If the domain nameis tagged for auction, a domain name is acquired at step 814 and allpotential buyers or interested entities are notified of the acquisitionand upcoming auction. This path ends the process at step 816. Thisprocess is referred to as “accelerated pinging” because it is morestreamlined than the standard pinging process of FIG. 6, and because itcan be set to repeat at an accelerated rate (compared to the standardpinging process) in preparation for the domain name's impendingexpiration date and deletion from the SRS.

Decoding Event Information

The advanced monitoring technology employed by aspects of the presentinvention (such as the event decoder routine of FIGS. 4 through 6) iscapable of processing information about real time events that iscommunicated through push, pull, or other communication strategies withdomain registrars or registries. Both RRP events and domain namesupdated in the Registrars WHOIS servers can be processed. These eventscan be transmitted through an API designed to transfer the events in asecure manner and enter the events into a queue for further processing.

FIG. 9 depicts a RRP and WHOIS event decoder flow process. The processbegins at step 900. A domain name event is then retrieved at step 902from the RRP and WHOIS event queue 904 for decoding. The RRP and WHOISevent queue receives input from individual registrars 906 a through 906c. The domain name that is the subject of the event retrieved at 902 isthen compared to the domain names in the desired domain name database atstep 908. If the domain name is not in the desired domain name database,statistics are accumulated from the event, but the event is otherwisedisregarded at step 910. The process then repeats with step 902. If thedomain name that is the subject of the event is in the database at step900, the system determines if it is an RRP event, at step 912. If it is,the RRP event is decoded at step 914. The decoding of the RRP event 914is more thoroughly illustrated in FIG. 10. After step 914, the processrepeats with step 902. If at step 912 it is determined that the event isnot an RRP event, the system can then continue with step 916 to decodethe event as a WHOIS event. The process of decoding a WHOIS event ismore thoroughly illustrated in FIG. 11. The process then returns to step902 and repeats.

RRP Event Decode

RRP events are decoded first. These events and actions can includedeletions, additions, modifications, renewals, or transfers of a domainname registration. A preferred embodiment of the present inventionhandles each of these events in the following manner. For deletions ofthe domain name record in a registry, the customer can be notified andthe domain name can be designated as a candidate for the acceleratedpinging process described previously. If the RRP event was an additionof a domain name record to a registry, the domain can be flagged forinclusion in any of several forms of periodic notifications that can bemade available to subscribers of services embodying the presentinventions. This could be an online posting made available through a Website, or an electronic journal, e-mail, or newsletter, or other forms ofcommunications. Making the customers aware of the addition of the domainname record can also lead to the customer requesting further services,such as services to monitor and acquire the domain name when theregistration expires. If the RRP event is a modification or transfer ofa domain name record, the customer requesting the monitoring service canbe notified of the event. If the RRP even was a renewal of the domainname registration, the customer of the monitoring service can benotified and the domain name can be removed from the accelerated pingingstatus (if, for example, it was designated for accelerated pingingbecause of an approaching registration expiration date).

For RRP events for which a customer receives notification, such as fordeletions, modifications, renewals, and transfers, the notification canbe provided immediately after decoding the event, or several events maybe decoded and aggregated, with notifications being sent to customersinforming them of all of the events simultaneously. In the case of atransfer RRP event, customers that have requested acquisition servicesto acquire or re-acquire a domain name once the prior registrationperiod ends can receive immediate notification that a transfer requesthas been made against the domain. Customers that have a lesser interestin the domain name, such as those that are only monitoring the domainname, but not requesting acquisition, can see the result of a transferaction after the fact from data comparisons of WHOIS data.

FIG. 10 illustrates the registrar to registry protocol (RRP) eventdecode process depicted as step 914 in FIG. 9. In FIG. 10, the processbegins at step 1000. The RRP events of FIG. 10 are divided into fourseparate sections for illustrative purposes. The presentation of theevent analysis process sections in series is for illustrative purposesand not meant to be limiting. Continuing with step 10, Section Aillustrates the handling of an RRP deletion event. Section B illustratesthe handling of an RRP addition event. Section C illustrates thehandling of an RRP renewal event. Finally, Section D illustrates thehandling of an RRP transfer event. Those skilled in the art will readilydetermine that there can be alternative configurations of the systemthat would prove equally successful. Those modifications are alsoconsidered part of the scope of the present invention as determined bythe attached claims.

The presence of an RRP deletion event is determined in step 1002. If thedetermination is made in step 1002 that there is no RRP deletion event,the system continues with the analysis of other types of events. If anRRP deletion event is detected in step 1002, the system next determinesif there is an acquisition customer at step 1004. If there is anacquisition customer, the acquisition customer is notified of thedeletion in step 1006. The domain is tagged for accelerated pinging instep 1008 and a determination is made in step 1010 whether or not thereis a monitoring customer. If there is not a monitoring customer, theprocess returns to step 1000. If there is a monitoring customer, theevent is recorded for notification to the monitoring customer at step1012. Continuing with step 1004, if there is no acquisition customer,the system determines if the domain is tagged for auction at step 1014.If the domain is tagged for auction, the process continues with step1008 as previously described. If the domain is not tagged for auction atstep 1014, the process continues with step 1012 as previously described,ultimately returning to step 1000.

If the determination is made in step 1002 that there is no deletionevent, the system next analyzes whether or not there was an additionevent at step 1016. If at step 1016 there is an addition event, thesystem next determines if there is an acquisition customer at step 1018.If there is no acquisition customer at step 1018, the process continuesby returning to the beginning 1000. If there is an acquisition customerdetected at 1018, the event is recorded for notification of theacquisition customer or monitoring customer at step 1020.

If there is no deletion event and no addition event, the systemdetermines whether there is a renewal event at step 1022. If a renewalevent is detected at step 1022, the system next determines if the domainname that is the subject of the renewal event was tagged for acceleratedpinging 1024. If it was not tagged for accelerated pinging, the systemdetermines if there is an acquisition customer at step 1026. If not, thesystem returns to the beginning 1000. Returning to step 1024, if thedomain name was tagged for accelerated pinging, the accelerated pingingstate is canceled 1028. The system then continues with step 1026 asbefore. If at step 1026 it is determined that there is an acquisitioncustomer, the acquisition customer is notified of the renewal event atstep 1030. The system then returns to the beginning 1000.

If there is no deletion event detected at step 1002, addition eventdetected at 1016, or renewal event detected at step 1022, the systemcontinues with a determination at step 1032 of whether there has been atransfer event. If there has not been a transfer event, the systemreturns to the beginning 1000. If there has been a transfer eventdetected at step 1032, the system next determines if the domain namethat is the subject of the event was tagged for accelerated pinging atstep 1034. If the domain name was not tagged for accelerated pinging,the system continues with a determination of whether there is anacquisition customer at step 1036. If the determination was made at step1034 that the domain name was tagged for accelerated pinging, theaccelerated pinging state is canceled 1038 before proceeding to step1036. If an acquisition customer is detected at step 1036, the customeris notified of the transfer action at step 1040. After the acquisitioncustomer is notified of the transition action at step 1040, or if thereis no acquisition customer at step 1036, the process returns to thebeginning 1000.

WHOIS Event Decode

A second type of event includes WHOIS events. These events typicallyaffect the registration information for a particular name. Thisregistration information is typically stored in WHOIS databases at theregistrar or registry level. When the customer first signs up foracquisition services or monitoring services for a domain name, areference copy of the domain name's registration record is captured.This “base” view will be the default data that future queries will becompared against until the “base” view changes, at which time the newerview becomes the new “base.” Any changes between the views will causethe customer to receive notice of changes made to the registrationrecords kept in the WHOIS database. Changes may just indicate updatesmade by the owner of the domain name, or they may be fraudulent changesto any of the registration data. FIG. 11 illustrates a preferred WHOISevent decode process. FIG. 11 begins at step 1100. The system nextqueries a registrar's WHOIS database 1102. The system then determines ifthere have been changes to the registration record 1104. If no changeshave been detected at step 1104, the process returns to the beginning1100. If changes to the registration record were detected at step 1104,the system proceeds with a determination at step 1106 of whether thereis an acquisition services customer for that domain name. If there is,the customer is notified of the change to the domain name registrationat step 1108 and the database record is updated at step 1110 to reflectthe registration record changes. The system returns to the beginning1100 after completion of step 1110. If no acquisition customer isdetected at step 1106, the system proceeds to determine, at step 1112,whether there is a monitoring services customer. If there is, thechanges to the domain name registration are recorded in step 1114 andthe system proceeds with step 1110 as previously described. If there isno monitoring customer, the system returns to the beginning 1100 and theprocess repeats.

The current registration system, the SRS, is defined as a “thinregistry.” In a thin registry, the registry only maintains a small partof the domain name's registration information. This informationtypically includes the following: domain name (second level domain, SLD,and the top level domain, TLD); creation, modification, and expirationdates for the domain name record; domain name server information;registrar of creation; and current holding registrar. In a thinregistry, the registrar of the domain name maintains the otherinformation about the domain names registered with them. Thisinformation includes registrant and contact information, such as:name(s), addresses, phone and fax numbers, and e-mail addresses.Information is frequently categorized as billing, administrative, andtechnical contact information. Under the current ICANN AccreditationAgreement, they also maintain the name server information.

Some newer registries have proposed, and some have actually implemented,a “thick registry” system. In a thick registry system, nearly all of theabove information is combined and kept at the registry level, and notwith the registrar. The monitoring, acquisition, and other technologiesof the present invention will continue to work and integrate with thickor thin registries. Rather than pinging or receiving pushed informationfrom various registrars, the registries would be the sources ofinformation and integration for technology consistent with the presentinvention. Establishing contractual relationships with the variousregistries or integrating with their databases would further aid thedissemination of information and the implementation of the technologiesembodying the present invention.

Auction Tagger

Another aspect of the present invention can use the data contained inthe desired domain name database 110 of FIG. 1, representing domain namedemand, and match that information with gathered informationrepresenting domain name supply. Requests to monitor a domain name, orrequests for acquisition can also be used to indicate domain namedemand. As shown by the seller database 114 of FIG. 1, the supply-sideinformation can be cataloged in a database of domain names thatindividuals wish to sell. One potential source of domain name supplyinformation can be through various Web site operators that maintain Websites specializing in advertising or otherwise indicating domain namesthat entities wish to sell. The result is the creation of a type ofdomain name auction site or service that facilitates transactionstransferring ownership of the domain names.

Once a domain reaches a predefined level of interest, that domain istagged as an auctionable domain. Interest in a domain name can be afunction of the number of interested parties, their level of interest,or other factors, weighted independently or in combination. For example,while the existence of several entities interested in a particulardomain name may meet the threshold for interest, so too may theexistence of one or two interested entities to whom the domain name isof particular importance. This information can be provided by theinterested entity. A daily run can be made against the database anddomain names reaching the threshold of interest are tagged. A domainname tagged in this manner can be monitored and acquired as it isdeleted, or the existing owner may be contacted. A domain name can beacquired for an entity that has requested acquisition services, or, itcan be acquired and held in escrow by an escrow agent pending theoutcome of any future auction. Owners of domains that are tagged ashaving an actionable level of interest can be contacted to see if theyhave an interest in auctioning their domain using an embodiment of thepresent invention. As used throughout this specification and theattached claims, the term “auction” is used broadly so as to encompasstransactions not traditionally referred to using that term, such as anexplicit unilateral offer to purchase or sell a domain name. If thenumber of domain name monitoring requests (or other indicator of domainname interest) indicates that the interest in a domain name is or hasfallen below the threshold interest level, the domain can be “untagged”for auction.

FIG. 12 diagrams an auction tagger process used to identify domain namessuitable for auctioning. FIG. 12 begins the process with step 1200. Thesystem selects a domain name by retrieving it from the queue at step1202. The system then determines if there is at least one interestedentity at step 1204. If there is not at least one interested entityidentified at step 1204, the system returns to the beginning 1200 andrepeats with a later identification of interested entities 1204. Ifthere is at least one interested entity identified at step 1204, thesystem proceeds with a determination, at step 1206, of whether thenumber of interested entities (or their individual or cumulative levelof interest) meets a predetermined threshold of interest. If thedetermination is made that the interest level does not meet thethreshold at step 1206, the process returns to the beginning 1200 andrepeats. If the determination is made at step 1206 that the interestlevel exceeds the predetermined threshold of interest, the domain nameis tagged for auction in step 1208 and the process returns to step 1200,repeating with the next domain name in the queue. It should also benoted that once a domain name is tagged for auction, separate procedurescan be implemented to facilitate the auction process. One such procedureis to notify the interested entities that the domain is available forauction or has been acquired and is tagged for auction. Another examplecould be to notify the registrant that there is sufficient interest foran auction, should the registrant be interested in transferring thedomain name. Communications can then be established between the sellerof the domain name registration and the potential buyers. Multiplebuyers can be asked to input bids during a set bidding period or in alive format, either in-person, over a phone, or via a Web site.

Avoiding Priority Contests

In the present invention, priority contests, or disputes regarding towhich interested entity a domain name should be registered, can beresolved, or avoided altogether, through implementation of afirst-in-time priority rule. While multiple interested entities canrequest acquisition services for a domain name, the system can limit theacquisition service to only one interested entity per domain name. Thefirst interested entity to request the acquisition service can begranted priority over any other interested entity. Should the domainname become available, it can automatically be registered for theinterested entity with the acquisition service. Because multipleentities can receive monitoring services without conflicts thoseservices do not have to be similarly limited to one entity.

The fact that there can be multiple interested entities requestingmonitoring services provides a convenient method for determining andcontinually monitoring the level of interest in any given domain name.Domain name related interest can be collected from registrar and otherdomain-related sites, including third party sources, world wide. Becausedomain names have to be registered online, tapping these major sourcesindicating domain name interest ensures a very accurate, thorough, andvaluable total representation of domain name interest. Each monitoringservice request indicates an entity that may have an interest inacquiring the domain name. Requests for acquisition services can alsoindicate demand for a domain name. Although implementation of prioritycontest rules may ensure that only one entity per domain name can beprovided acquisition services, the number of interested entities thatrequest acquisition services (even if prior contest rules prevent theirrequests from being granted), combined with the number who requestmonitoring services can indicate demand for the domain name.Alternatively, direct input can be received from interested entitiesthat would like to make an offer for a particular domain name. Directsolicitations can be received through such methods as a telephone callcenter, e-mail, or a Web site with an HTML or similar form for receivinginput from a remote computer user. If there are enough entitiesinterested in a particular domain name, or, if there are only a fewinterested entities but the level of interest is high enough, thatdomain name can be auctioned among the interested entities. While aninterested entity using the acquisition service of the present inventionwill automatically obtain the domain name when it becomes available forregistration, that entity can also be informed that there are severalother interested entities that have requested monitoring services (orunfulfilled requests for acquisition services) and are potentiallyinterested in acquiring the name. This informs the registrant that thedomain name is a good candidate for an auction or potential transferthrough resale. By aggregating buyer demand, in addition to sellerdemand, embodiments of the present invention can establish an effectiveelectronic auction or business-to-business exchange for domain names.One or more potential sellers can be matched with one or more potentialbuyers in a “domain name market.”

It will be obvious to those having skill in the art that many changesmay be made to the details of the above-described embodiment of thisinvention without departing from the underlying principles thereof. Thescope of the present invention should, therefore, be determined onlyaccording to the claims made thereto.

1. A computer-implemented method for Internet domain name managementcomprising the steps of: (a) provisioning a web application having afront end that receives requests from customers wanting to registerselected domain names that are already registered to another entity; (b)maintaining a customer database accessible to the web application forstoring and retrieving information associated with each customer whomakes a request to register a selected domain name via the webapplication, including identification of the selected domain name; (c)obtaining computer access to domain name registration data stored in adatabase as part of the Internet shared registration system, andchecking the domain name registration data to determine whether anextant registration of a selected domain name identified in the customerdatabase has expired; (d) if the selected domain name registration hasexpired, monitoring communications between the sponsoring registrar ofthe expired domain registration and the corresponding domain nameregistry, the monitoring including a procedure for detecting a deletecommand from the sponsoring registrar to delete the selected domain namefrom the corresponding registry; and (e) if a delete command is detectedin the monitored communications to delete one of the selected domainnames identified in the customer database, re-allocating the selecteddomain name to the corresponding customer identified in the database whorequested the registration, by automatically sending an electronicinstruction to the sponsoring registrar who issued said delete command;(f) wherein the instruction is sent to the registrar prior to deletionof the selected domain name from the corresponding registry, so that thedomain name does not become available to the public for a newregistration.
 2. A computer-implemented method according to claim 1wherein the procedure for detecting a delete command includes executingan event decoder software routine.
 3. A computer-implemented methodaccording to claim 1 including: forming contractual alliances with oneor more partner domain name registrars; and wherein the said sponsoringregistrar of the selected domain name is one of the partner domain nameregistrars.
 4. A computer-implemented method according to claim 1including: maintaining a seller database to store information aboutentities wishing to sell a registered domain name; comparing thecustomer database storing information associated with each customer whomakes a request to register a selected domain name to the sellerdatabase, to identify whether the selected domain name matches a domainname listed in the seller database; and if a domain name matches,contacting the seller listed in the seller database to facilitate a saleto the corresponding customer listed in the customer database whorequested the domain name.
 5. A computer-implemented method according toclaim 1 including: if a delete command is detected in the monitoredcommunications to delete one of the selected domain names identified inthe customer database, checking the customer database to determinewhether more than one customer has requested to register the selecteddomain name; and if more than one customer has requested to register theselected domain name, instead of re-allocating the selected domain name,commencing an online auction of the selected domain name among thecustomers listed in the customer database who had previously requestedto register the selected domain name.
 6. A computer-implemented methodaccording to claim 5 and further comprising: estimating when theselected expired domain name is expected to delete from thecorresponding registry; and conducting the auction within the timeremaining before the selected expired domain name deletes from thecorresponding registry; and re-allocating the domain name to a winner ofthe auction.